[ Prev Page | Goto Content | Next Page ] =/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\ ICMP wakeup backdoors takeover [+] .............................. [+] После выхода m00-bdpack мы тут призадумались, а многие ли юзают этот warez? В любом случае, мы решили рассказать о том, на сколько реально захватить box, на котором висит icmp-wakeup бекдор. Сперва рассмотрим то как работает такой бекдор: снифаем входящие icmp пакеты. Далее смотрим, какая инфа в нём содержится и если она совпадает с ключом то пускаем в систему (вешаем шелл, или конектимся обратно). Формат icmp-пакета: 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICMP_type | ICMP_code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Argz | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data if need... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ICMP_type - занимает 8 бит, тоесть принимает 256 значений ICMP_code - тоже 1 байт, тоже 256 значений Checksum - 16 бит, 65536 значений Argz - тут уже содержимое зависит от типа и кода сообщения. Вот как это юзает rashray: struct ouricmp { unsigned long int spit; /* icmp_type, icmp_code, checksum */ unsigned short int flag; /* биты 0-15 поля argz */ unsigned short int port; /* биты 16-31 поля argz*/ }; Тут возникает ещё одно значение для перебора: flag - 2 байта, и снова у нас 65536 вариантов... В офицальной версии bdpack'a идентификация только по полю flag. При среднем канале 65536 вариантов перебирается за 5-7 минут.. В общем офицальная версия тут ломается без особого труда. Теперь поговорим о приватной ( или модифицированной) версии: что тут может быть? Если не очень извращяться то такие варианты: 1. icmp_type - 256 значнеий 2. icmp_code - 256 значений 3. flag - 65536 значений 4. port - 65536 значений Но это только теория. А вот какие особенности в действительности: 1. вполне вероятно что возникнут проблемы с доставкой/обработкой icmp-пакетов со значениями type и code больше 16. Вот типы icmp-сообщений, описанных в RFC 792 : 0 Echo Reply 3 Destination Unreachable 4 Source Quench 5 Redirect 8 Echo 11 Time Exceeded 12 Parameter Problem 13 Timestamp 14 Timestamp Reply 15 Information Request 16 Information Reply Короче, тут нам остаётся (по rfc) только 11 типов. Не всё так плохо в общем ( на самом деле типов побольше, просто rfc старый ;)) Да, кстати некоторые типы icmp-сообщений не удастся отправить в режиме пользователя через raw sock (i.e. if type = 5 on kernel 2.4.18, по крайней мере тестилось на нём). В зависимости от того, какая ось могут быть особенности обработки пакетов. 2. также rfc лимитирует и icmp_code: +--------+------------------------------------+ | Type: | Code: | +--------+------------------------------------+ | 0 | 0 | +--------+------------------------------------+ | 3 | 0 (Net unreachable) | | | 1 (Host unreachable) | | | 2 (Protocol unreachable) | | | 3 (Port unreachable) | | | 4 (Datagram too big) | | | 5 (Source route failed) | | | 13 (Communication | | | Administratively Prohihibited) | +--------+------------------------------------+ | 4 | 0 | +--------+------------------------------------+ | 5 | 0 (в данную сеть) | | | 1 (на данный хост) | | | 2 (в данную сеть с данным | | | TOS ) | | | 3 (на данный хост с данным | | | TOS ) | +--------+------------------------------------+ | 8 | 0 | +--------+------------------------------------+ | 11 | 0 (при передаче) | | | 1 (при сборке) | +--------+------------------------------------+ | 12 | 0 (ошибка в IP-заголовке) | | | 1 (отсутсвует необходимая | | | опция ) | +--------+------------------------------------+ | 13 | 0 | +--------+------------------------------------+ | 14 | 0 | +--------+------------------------------------+ | 15 | 0 | +--------+------------------------------------+ | 16 | 0 | +--------+------------------------------------+ Тут всё тоже пучком. Максимум - 7 вариантов. 3. Checksum Ну это трогать (по rfc опять же) нельзя. На практике... хз. Не думаю что это хорошая идея )) Единственная трудность: 3 варианта расположения флага и порта в argz: 1. 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flag | Port | (original) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2. 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port | Flag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ну и третий вариант, который мало вероятен но тем не менее... 0 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Не думаю что m00-membaz будут отводить на флаг 32 бита. Иначе тут получается 65536*65536 вариантов... получается диапазон 0x00000000 - 0xffffffff - от таких чисел выпадаешь в осадок. Для сравнения размер виртуальной памяти процесса такой же, а всего он даёт 4 gb адресного пространстава. Мрак короче... Итак, у нас 6-7 (в среднем) допустимых значений icmp_type и icmp_code, значений флага - 65536. И скажем мы будем проверять 2 типа расположения flag и port... Прикинем: 6*7*65536*2 = 84*65536 = 5.505.024 вариантов. Учитывая, как я уже говорил,что на перебор 65536 вариантов при среднем канале уходит максимум 8 минут, получается что при максимальном извращении ( не учитывая вариант когда флаг равен 4 байта ) на брутфорс уходит 84*8 = 672 минут = 11 часов 12 минут ;))) А если юзать много машин... короче реально наятнуть даже мега-приватный бокс. Идеи реализации: можно пускать в одном процесе (fuck threadz!!) такой перебор, в двух других повесить udp и tcp сокет и слушать -ловим connect-back. А ещё один процесс должен кадждые секунд 20 проверять -может шелл уже ждёт на указанном tcp или udp порту на удалёной машине. Ну и организовать связь между ними, к примеру с помощью сигналов. End... p.s. Если кому нужен пример - include/fuck_iwbdz.c [ Prev Page | Goto Content | Next Page ]